Meshlink v1.3 board updates and heartbeat LED fixes - #11654

🏁 Script executed:

printf '%s\n' '--- applicable instructions ---'
cat .github/copilot-instructions.md
printf '%s\n' '--- repository knowledge scopes ---'
find /tmp/coderabbit-repo-knowledge/meshtastic-firmware-d6b70ec8 -maxdepth 2 -type f -name '*.md' -print
printf '%s\n' '--- target file ---'
cat -n variants/nrf52840/meshlink/variant.h | sed -n '1,70p'
printf '%s\n' '--- directly bound LED/watchdog definitions and call sites ---'
rg -n -S 'LED_HEARTBEAT|StatusLEDModule|watchdog|Watchdog|MeshLink|meshlink' \
  variants/nrf52840/meshlink src modules .github 2>/dev/null | head -250

Repository: meshtastic/firmware

Length of output: 50378

🏁 Script executed:

printf '%s\n' '--- relevant repository guidance and learnings ---'
for f in /tmp/coderabbit-repo-knowledge/meshtastic-firmware-d6b70ec8/*/*.md; do
  case "$f" in
    */learnings/*|*/architecture/*|*/conventions/*)
      if grep -Eqi 'LED|watchdog|MeshLink|charging|StatusLED' "$f"; then
        echo "### $f"
        cat "$f"
      fi
      ;;
  esac
done
printf '%s\n' '--- target variant ---'
cat -n variants/nrf52840/meshlink/variant.h | sed -n '1,55p'
printf '%s\n' '--- relevant source files ---'
git ls-files | grep -E '(^|/)(StatusLEDModule|Watchdog|watchdog|PowerFSM|Charging|MeshLink|meshlink)' | head -100
printf '%s\n' '--- relevant symbols ---'
rg -n -S --glob '*.{cpp,h,hpp,cc,hh}' \
  'LED_HEARTBEAT|StatusLEDModule|watchdog|Watchdog|charging|Charging|MESH[Ll]ink' \
  variants/nrf52840/meshlink src | head -300

Repository: meshtastic/firmware

Length of output: 23607

🏁 Script executed:

printf '%s\n' '--- relevant repository guidance and learnings ---'
for f in /tmp/coderabbit-repo-knowledge/meshtastic-firmware-d6b70ec8/*/*.md; do
  if grep -Eqi 'LED|watchdog|MeshLink|charging|StatusLED' "$f"; then
    echo "### $f"
    cat "$f"
  fi
done
printf '%s\n' '--- target variant ---'
cat -n variants/nrf52840/meshlink/variant.h | sed -n '1,55p'
printf '%s\n' '--- relevant source files ---'
git ls-files | grep -E '(^|/)(StatusLEDModule|Watchdog|watchdog|PowerFSM|Charging|MeshLink|meshlink)' | head -100
printf '%s\n' '--- relevant symbols ---'
rg -n -S --glob '*.{cpp,h,hpp,cc,hh}' \
  'LED_HEARTBEAT|StatusLEDModule|watchdog|Watchdog|charging|Charging|MESH[Ll]ink' \
  variants/nrf52840/meshlink src | head -300

Repository: meshtastic/firmware

Length of output: 23607

🏁 Script executed:

printf '%s\n' '--- StatusLEDModule implementation ---'
cat -n src/modules/StatusLEDModule.cpp | sed -n '1,180p'
printf '%s\n' '--- StatusLEDModule declaration ---'
cat -n src/modules/StatusLEDModule.h | sed -n '1,125p'
printf '%s\n' '--- MeshLink variant watchdog setup ---'
cat -n variants/nrf52840/meshlink/variant.cpp | sed -n '1,45p'
cat -n variants/nrf52840/meshlink/variant.h | sed -n '105,145p'
printf '%s\n' '--- watchdog thread implementation and registration ---'
cat -n src/watchdog/watchdogThread.cpp | sed -n '1,70p'
cat -n src/modules/Modules.cpp | sed -n '115,145p;275,295p'
printf '%s\n' '--- nRF52 main watchdog path ---'
cat -n src/platform/nrf52/main-nrf52.cpp | sed -n '350,385p;440,470p'

Repository: meshtastic/firmware

Length of output: 20180

🏁 Script executed:

printf '%s\n' '--- MeshLink build contract ---'
cat -n variants/nrf52840/meshlink/platformio.ini
rg -n -S --glob '*.{h,hpp,cpp,ini,json}' \
  'HAS_HARDWARE_WATCHDOG|HARDWARE_WATCHDOG_(DONE|WAKE|TIMEOUT)|APP_WATCHDOG_SECS|MeshLink' \
  variants src boards | head -200
printf '%s\n' '--- remaining LED implementation ---'
cat -n src/modules/StatusLEDModule.cpp | sed -n '180,330p'
printf '%s\n' '--- nRF52 watchdog channel allocation ---'
rg -n -S --glob '*.{cpp,h,hpp}' \
  'nrfx_wdt_channel_alloc|nrfx_wdt_channel_feed|HARDWARE_WATCHDOG_DONE|HARDWARE_WATCHDOG_WAKE' \
  src variants

Repository: meshtastic/firmware

Length of output: 13420

🏁 Script executed:

printf '%s\n' '--- reviewed change ---'
git diff --unified=20 -- variants/nrf52840/meshlink/variant.h src/modules/StatusLEDModule.cpp variants/nrf52840/meshlink/variant.cpp
printf '%s\n' '--- pre-change target and directly related source ---'
git show HEAD^:variants/nrf52840/meshlink/variant.h | sed -n '24,38p'
git show HEAD^:src/modules/StatusLEDModule.cpp | sed -n '105,165p'
printf '%s\n' '--- all MeshLink-specific watchdog symbols in current and parent revisions ---'
for rev in HEAD HEAD^; do
  echo "### $rev"
  git grep -n -E 'PIN_WD_EN|HAS_HARDWARE_WATCHDOG|HARDWARE_WATCHDOG_|LED_HEARTBEAT' "$rev" -- variants/nrf52840/meshlink src/modules/StatusLEDModule.cpp src/watchdog 2>/dev/null
done

Repository: meshtastic/firmware

Length of output: 6558

🌐 Web query:

Meshtastic firmware PR 11654 MeshLink watchdog StatusLEDModule charging LED_HEARTBEAT

💡 Result:

Based on the current state of the Meshtastic firmware repository as of August 29, 2026, there is no direct pull request identified as #11654. The latest development activity includes pull requests such as #11577 [1] and #11521 [2]. Regarding the technical components mentioned: StatusLEDModule: This module manages device LED states, including charging, charged, and heartbeat behaviors [3][4][5]. Recent refactoring consolidated LED control (previously scattered in main.cpp) into this module [4]. LED_HEARTBEAT: This is a hardware-specific configuration macro used to define a dedicated heartbeat LED pin (e.g., on the Thinknode M4) [3]. When defined, the StatusLEDModule manages this pin to provide a periodic "heartbeat" pulse, distinct from the primary charge/power LED [3][5]. Users can disable this default heartbeat behavior via the device configuration setting led_heartbeat_disabled [3][6]. Charging/Watchdog Interaction: The StatusLEDModule logic explicitly manages power states (discharging, charging, charged, and critical) [5]. In specific hardware configurations (like those utilizing LED_HEARTBEAT), the module ensures that the charging LED is explicitly turned off or prioritized to prevent conflicts with the heartbeat signal [3]. While there is no specific "MeshLink watchdog" module named in this context, the firmware uses various watchdog and state-machine mechanisms to ensure reliable device operation, such as managing power states [3][4] and time synchronization [7][8].

Citations:

• 1: GitHub pull request 11577 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 2: GitHub pull request 11521 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 3: https://github.com/meshtastic/firmware/blob/ec5d2303/src/modules/StatusLEDModule.cpp
• 4: GitHub pull request 9512 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 5: https://github.com/meshtastic/firmware/blob/ec5d2303/src/modules/StatusLEDModule.h
• 6: https://meshtastic.org/docs/configuration/radio/device/
• 7: GitHub pull request 11274 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 8: GitHub pull request 10737 in meshtastic/firmware (link omitted to avoid creating a cross-reference)

🌐 Web query:

site:github.com/meshtastic/firmware/pull/11654 MeshLink

💡 Result:

PR #11654 — “Meshlink v1.3 board updates and heartbeat LED fixes” is currently open. It includes:

• MeshLink V1.3 hardware/pin updates
• Heartbeat LED and watchdog-timer fixes
• User-button, GPS, serial, and status-LED mapping changes
• Corrected INA219 battery-current readings
• Increased e-ink fast-refresh limit

It has 4 commits and was tested on V1.2 and V1.3 boards. [1]

🌐 Web query:

"Meshlink v1.3 board updates and heartbeat LED fixes" watchdog charging StatusLEDModule

💡 Result:

The MeshLink V1.3 board, developed by LoraItalia, uses an NRF52840 processor and includes features such as an integrated hardware watchdog, MPPT solar charging support, and various peripheral options [1]. Board Updates and Configuration Recent firmware developments for the MeshLink board have focused on refining its hardware support, including updates to platformio.ini and variant.h files [2][3]. These updates have addressed issues with GPS serial pin mapping, enabled the correct GPS enable pin, and standardized the platformio.ini configuration to align with other boards in the Meshtastic firmware ecosystem [2][3]. Additionally, optimizations have been implemented for E-INK screen responsiveness, and a default GPIO (10) has been assigned for the user button [2][3]. Watchdog and Power Management The MeshLink board is explicitly designed with a hardware watchdog [1]. In the board's variant.h file, PIN 25 is defined as PIN_WD_EN to manage this watchdog [4]. It is a critical requirement that this pin be disabled when the CPU enters sleep mode; otherwise, the timer will expire and cause the CPU to reboot [4]. StatusLEDModule and Charging The StatusLEDModule in the Meshtastic firmware manages device status indicators, including those for charging status and Bluetooth state [5][6]. Support for detecting charging states was specifically added to this module to ensure correct LED feedback during charge cycles [7]. The module processes power status updates (e.g., USB connection, charging, charged, discharging, critical battery levels) and updates the assigned LEDs accordingly [5]. For boards utilizing PMUs (Power Management Units), the module interfaces with the PMU to control charging LEDs [5]. Heartbeat LED Behavior Issues involving the heartbeat LED remaining solid rather than blinking are often related to specific board variant configurations or power-saving states [8][9]. On NRF52-based boards, if the system perceives the battery voltage as being below a certain threshold or detects power-loss conditions, it may alter LED behavior as part of its power-saving logic [9]. Users encountering solid LED behavior are advised to verify their board's variant definitions (e.g., LED_STATE_ON settings) and ensure that battery voltage reporting is correctly calibrated [9].

Citations:

• 1: https://github.com/meshtastic/firmware/blob/b2bda3b0/variants/nrf52840/meshlink/platformio.ini
• 2: GitHub pull request 9728 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 3: GitHub pull request 9728 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 4: https://github.com/meshtastic/firmware/blob/ec5d2303/variants/nrf52840/meshlink/variant.h
• 5: https://github.com/meshtastic/firmware/blob/ec5d2303/src/modules/StatusLEDModule.cpp
• 6: https://github.com/meshtastic/firmware/blob/ec5d2303/src/modules/StatusLEDModule.h
• 7: GitHub pull request 9050 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 8: GitHub issue 10114 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 9: GitHub issue 4341 in meshtastic/firmware (link omitted to avoid creating a cross-reference)

🌐 Web query:

github meshtastic firmware 11654 "watchdog" "charging"

💡 Result:

There is no evidence of a specific Meshtastic firmware issue tied to the number "11654" in the context of watchdog or charging problems [1][2][3][4]. The number 11654 appears in unrelated technical contexts, such as historical Linux kernel build logs [5][6] and Patton SmartWare release notes [7]. Regarding Meshtastic firmware, charging and watchdog-related issues are well-documented but are typically associated with specific hardware behaviors rather than a single numerical identifier: 1. Charging and Deep Sleep Loops: On some ESP32-based devices, intelligent charging controllers may cause the device to enter a deep sleep loop because the battery voltage rises slowly, preventing the device from detecting a full or sufficient charge [1]. 2. NRF52 Brownouts: NRF52 boards can experience lockups when battery voltage sags, sometimes triggering power-fail warnings or requiring physical resets because the hardware brownout reset (BOR) is factory-fixed and cannot always recover without a complete power cycle [2][3]. 3. Heltec T114 Lockups: These are often linked to unregulated solar panels providing over-voltage, which causes the charging chip to trigger protection and effectively lock the device [3]. If you are encountering a specific watchdog or charging error, it is recommended to search the official Meshtastic GitHub repository issues using descriptive keywords like "solar charging," "deep sleep," "brownout," or the specific model of your hardware (e.g., "T114," "ESP32," "RAK") [1][2][3].

Citations:

• 1: GitHub issue 4828 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 2: GitHub issue 4378 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 3: GitHub issue 8468 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 4: GitHub issue 4555 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 5: https://www.landley.net/notes-2006.html
• 6: https://landley.net/notes-2006.html
• 7: https://www.patton.com/support/upgrades/files/release/smartnode_rn6.t_2014-05-28.pdf

🌐 Web query:

MeshLink v1.2 v1.3 GPIO 24 GPIO 25 hardware watchdog heartbeat LED

💡 Result:

In the MeshLink hardware configuration (nRF52840-based board developed by LoraItalia), specific GPIO pins are designated for status indication and hardware watchdog management [1][2][3]. According to the official board variant files (e.g., variant.h), the hardware functions are defined as follows: - GPIO 24: This pin is assigned to the status LED (PIN_LED1) [1][4]. It functions as a heartbeat or status indicator, with the LED state being active-low (LED_STATE_ON = 0) [1][4]. - GPIO 25: This pin serves as the hardware watchdog enable pin (PIN_WD_EN) [1]. It is used to enable or disable the external hardware watchdog [1]. Crucially, this pin must be disabled when the CPU enters sleep mode; otherwise, the timer will expire and the watchdog will trigger a CPU reboot [1]. These definitions are consistent across recent firmware configurations for the MeshLink board [1][5][6]. The MeshLink board integrates these features to support autonomous operations, particularly for remote nodes or repeaters where hardware-level monitoring is required [2][7][3].

Citations:

• 1: https://github.com/meshtastic/firmware/blob/ec5d2303/variants/nrf52840/meshlink/variant.h
• 2: https://github.com/meshtastic/firmware/blob/b2bda3b0/variants/nrf52840/meshlink/platformio.ini
• 3: GitHub pull request 5736 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 4: fifieldt@8f630bf
• 5: GitHub pull request 9728 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 6: GitHub pull request 9728 in meshtastic/firmware (link omitted to avoid creating a cross-reference)
• 7: GitHub issue 2032 in meshtastic/firmware (link omitted to avoid creating a cross-reference)

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- repository instructions ---'
cat .github/copilot-instructions.md
printf '%s\n' '--- scoped repository knowledge ---'
find /tmp/coderabbit-repo-knowledge/meshtastic-firmware-d6b70ec8 -maxdepth 2 -type f -name '*.md' -print
printf '%s\n' '--- target configuration ---'
cat -n variants/nrf52840/meshlink/platformio.ini | sed -n '30,48p'
printf '%s\n' '--- display implementation symbols ---'
rg -n -C 8 'EINK_LIMIT_FASTREFRESH|EINK_LIMIT_GHOSTING_PX|GxEPD2_213_B74|fast.?refresh|ghost' src variants

Repository: meshtastic/firmware

Length of output: 50378

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- target configuration ---'
cat -n variants/nrf52840/meshlink/platformio.ini | sed -n '1,55p'
printf '%s\n' '--- relevant implementation references ---'
rg -n -C 12 --glob 'EInkDynamicDisplay.cpp' --glob '*.h' --glob '*.cpp' \
  'EINK_LIMIT_FASTREFRESH|EINK_LIMIT_GHOSTING_PX|fastRefresh|fast.?refresh|ghosting' src variants
printf '%s\n' '--- GxEPD2_213_B74 bindings ---'
rg -n -C 8 'GxEPD2_213_B74|GxEPD2_213' variants src

Repository: meshtastic/firmware

Length of output: 50376

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- exact limit definitions and uses ---'
rg -n -C 5 'EINK_LIMIT_FASTREFRESH|EPD_FULLSLOW_PERIOD|EINK_LIMIT_GHOSTING_PX' \
  --glob '*.h' --glob '*.cpp' --glob '*.ini' --glob '*.py' .
printf '%s\n' '--- dynamic display control flow ---'
cat -n src/graphics/EInkDynamicDisplay.cpp | sed -n '1,430p'
printf '%s\n' '--- dynamic display declarations and base includes ---'
cat -n src/graphics/EInkDynamicDisplay.h | sed -n '1,140p'
printf '%s\n' '--- local panel/driver references ---'
rg -n -C 5 'GxEPD2_213_B74|EINK_DISPLAY_MODEL|USE_EINK_DYNAMICDISPLAY|EINK_WIDTH|EINK_HEIGHT' \
  variants/nrf52840 src platformio.ini

Repository: meshtastic/firmware

Length of output: 50376

🌐 Web query:

Good Display GDEY/B74 2.13 inch e-paper GxEPD2_213_B74 partial refresh full refresh every five partial updates ghosting

💡 Result:

The Good Display GDEY0213B74 2.13-inch e-paper display supports both full and partial refreshes [1][2]. When using the GxEPD2 library, the GxEPD2_213_B74 driver is designed to handle these operations, including specific handling for partial updates [3][4][5]. Regarding the specific concern of ghosting and partial refresh frequency: 1. Ghosting and Partial Refresh: E-paper displays naturally accumulate artifacts ("ghosting") when using partial updates because they do not fully reset the pixels to a neutral state with every refresh [6]. To manage this, it is standard practice to perform a full refresh periodically [6][7]. A common recommendation is to perform a full refresh every 5 to 10 partial updates, depending on the application and how much content changes on the screen [6][7]. 2. Partial vs. Full Screen Refresh: On many panels with SSD controllers (like the SSD1680 used in the GDEY0213B74), "partial update" technically refers to updating a specific window, but many drivers perform a differential refresh on the full screen anyway [6][8]. If your application involves multiple elements changing at different times, it is often more efficient and cleaner to trigger a full-screen refresh to avoid the "ghost frame" or artifacts that can appear around defined partial windows [6][8]. 3. Library Configuration: The GxEPD2 library includes mechanisms to control this behavior [5]. You can monitor the number of partial updates in your code and trigger a full update (display.refresh(false)) once the threshold (e.g., every 5 updates) is reached [6][7]. If ghosting is excessive even with frequent full updates, ensuring that you are using the correct GxEPD2_213_B74 driver class and that your initialization sequence matches the manufacturer's recommendations is crucial [5]. Some developers also successfully mitigate ghosting by re-initializing the display or forcing a full refresh sequence after a certain period of continuous partial updates [9][7]. In summary, ghosting is an inherent characteristic of partial refresh in electrophoretic displays [6]. Performing a full refresh every 5 partial updates is a widely accepted heuristic to maintain image quality [6][7]. If you notice persistent issues, try increasing the frequency of full refreshes or switching to full-screen updates if the performance impact allows [6][8].

Citations:

• 1: https://www.good-display.com/companyfile/635.html
• 2: https://microhello.com/products/gdey0213b74,213-inch-e-ink-display-supports-15s-fast-refresh-for-e-paper-price-tag
• 3: https://docs.paperd.ink/PaperdInk-Library/GxEPD2__213__B74_8h_source.html
• 4: https://docs.paperd.ink/PaperdInk-Library/GxEPD2__213__B74_8cpp_source.html
• 5: https://github.com/ZinggJM/GxEPD2
• 6: https://forum.arduino.cc/t/gxepd2-partial-updates-general-usage/1235001/1
• 7: https://github.com/ZinggJM/GxEPD/blob/master/examples/PartialUpdateTest/PartialUpdateTest.ino
• 8: https://forum.arduino.cc/t/gxepd2-partial-updates-general-usage/1235001/2
• 9: https://www.reddit.com/r/Bjorn_CyberViking/comments/1e4u1k4/solved_ghosting_issue_on_waveshare_213_displays/

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- fast-refresh decision path ---'
cat -n src/graphics/EInkDynamicDisplay.cpp | sed -n '145,190p;300,355p;400,457p'
printf '%s\n' '--- model-specific configuration and dependency pin ---'
cat -n variants/nrf52840/meshlink/platformio.ini | sed -n '23,52p'
printf '%s\n' '--- local references to B74 and ghosting policy ---'
rg -n -C 4 'GxEPD2_213_B74|EINK_HASQUIRK_GHOSTING|EINK_HASQUIRK_VICIOUSFASTREFRESH|EINK_LIMIT_GHOSTING_PX' \
  variants/nrf52840 src/graphics

Repository: meshtastic/firmware

Length of output: 32400